A typical centralized train-control system 100 is depicted in FIG. 1. The system includes network control center 102, communications 108, train-borne equipment 112 (e.g., location determining device, etc.) on train 110, and trackside infrastructure 116, such as control points, defect detectors, rail-rail interfaces, and infrastructure associated with grade crossing 114 (e.g., predictor controllers, crossing warning devices, etc.).
In such a system, it is important to distinguish between “vital” and “non-vital” components and systems. The term “vital” means that a function must be done correctly or the failure to do so must result in a safe state. “Vital” is synonymous with “safety-critical.”
In the context of FIG. 1 of system 100, a safety-critical centralized train-control system must have the means to ensure that no data that could compromise safety is sent to trackside or train-borne systems or equipment. Traditionally, this issue has been addressed by considering the entire centralized server application to be safety-critical. Indeed, as indicated in FIG. 1, only Dispatching Systems 106 in network control center 102 and Communications 108 are non-vital. Logic exists to take “non-vital” data from the entire enterprise (e.g., dispatch system, communications network, etc.) and use it in a “vital” manner.
Of particular note is the fact that the centralized train control server, as well as train-borne and trackside infrastructure, are vital.
Designing, developing, and testing safety-critical (“vital”) applications is performed at a much lower productivity than non-vital applications. Furthermore, proving that an application is vital is much more time consuming and problematic as the size of the application increases. As such, the cost of developing and certifying the entire application as safety-critical or vital is prohibitive.